Es gibt ca. 9 Fachdienst VSDM 2 Betreiber, die von 94 gesetzliche Krankenkassen beauftragt werden bzw. in einer vertraglichen Beziehung mit diesen stehen. Die Vergangenheit hat gezeigt, dass es des öfteren vorkommt, dass Krankenkassen den Betreiber wechseln. Ein Primärsystem kennt auf Basis der IK-NR immer nur die die Krankenkasse zu einem bestimmten Patienten, jedoch nicht bei welchem Betreiber die Krankenkasse aktuell ist.

1. Der ZETA-Client kann das protected resource metadata Dokument nicht standardkonform gemäß https://www.rfc-editor.org/rfc/rfc9728.html#name-protected-resource-metadata-v abrufen und verarbeiten, wodurch die VSDM-spezifischen ZETA-Konfiguratonen nicht ermittelt werden können.
2. Anfragen am /authorize Endpunkt des AuthZ-Server resultieren aufgrund des Kostenträger-spezifischen claims "aud" in der Anfrage in Kostenträger-spezifische Access-Token. Dies führt zu n (mit n = Anzahl der Kassen) durch das Primärsystem zu verwaltende Access-Token, da der ZETA Client vom VSDM2 Client mit einem kompletten HTTP Request (mit genau einer URL == Audience) angefragt wird und auf Basis dessen ein Access- und Refresh-Token immer für die angeforderte Audience (Endpunkt des RS) und zugehörigem Scope ausgestellt wird.
3. Anfragen an den /vsdmservice Endpunkt des Resource Server resultieren aufgrund des Kostenträger-spezifischen HOST Parameter im HTTP-Request des Primärsystem in ebenso Kostenträger-spezifische ASL-Kanäle. Dies führt bis zu n (mit n = Anzahl der Kassen) durch das Primärsystem zu verwaltende ASL-Kanäle bzw. ASL Schlüsselpaare, da ein ASL Kanal immer für einen bestimmten Host (== FQDN im CNAME) aufgebaut werden muss.

Der hier skizzierte Lösungsvorschlag sieht vor, dass die vollständige Fachdienstlokalisierung eines Clientsystems über einen eigens von der gematik angebotenen Endpunkt erfolgt. Dieser Endpunkt liefert eine, pro Betriebsumgebung konfigurierte, statische JSON-Datei (catalog.json) aus, welche die Verknüpfung von IK-Nummer zu Betreiber-FQDN für mandantenspezifische TI 2.0 Fachdienste (wie z.B. VSDM 2) beinhaltet. Dabei entfällt die derzeit bekannte Fachdienstlokalisierung mittels DNS.

Dabei werden weder Änderungen am ZETA-Guard, noch unmittelbar am Fachdienst VSDM 2 erforderlich. Die nachfolgend beschriebenen Änderungen erhöhen die Lesbarkeit der Spezifikation und erklären hauptsächlich die Fachdienstlokalisierung aus Sicht eines Clientsystems. Es finden weiterhin Maßnahmen und Anpassungen zur Qualitätssicherung statt.

Die Änderung basiert auf dem aktualisierten Vorabveröffentlichungspaket gemSpec_VSDM_2_V1.4.0_CC2

Dieser Pull Request löst den unter #113 Erstellten ab.